Dynamic customer vlan identifiers in a telecommunications network

ABSTRACT

A method for transmitting data over networks includes associating Customer Edge Virtual Local Area Network (CE-VLAN) identifiers with an Ethernet Virtual Connection (EVC). Each of the CE-VLAN identifiers is assigned to a respective Virtual Private Cloud (VPC) of a cloud computing environment and the EVC extends between a first network and the cloud computing environment through a second network. The EVC is also configured to transmit packets including any of the CE-VLAN identifiers to the cloud computing environment. The method further includes transmitting a packet received from the first network and including one of the CE-VLAN identifiers to the cloud computing environment using the EVC.

TECHNICAL FIELD

Aspects of the present invention generally relate to systems and methodsfor implementing a telecommunications network, and more specifically forexchanging traffic between a network and multiple virtual resources of acloud environment over the telecommunications network using a singleconnection.

BACKGROUND

Telecommunication or other types of computer networks provide for thetransmission of information. Such information may involve voice, data,multimedia information, software (including patches and updates), andvarious other forms of digital content, and digital services, among manyother things. In addition, telecommunication networks often offerfeatures and/or services to the customers of the network that provideflexible and varied ways in which the communications are transmittedover the network. For example, some telecommunication networks provideInternet access to its customers, long distance voice capabilities, highdefinition audio and/or video communication capabilities, and the like.In other examples, the telecommunication network may be utilized toprovide connectivity to one or more cloud-based resources offered by athird party. In other words, customers or other users may purchase,acquire, or otherwise obtain permission to use resources of a publicand/or private cloud service to virtualize one or more of processes andconnect to such resources through a telecommunications network.

Users may purchase or otherwise have access to multiple resources from apublic and/or private cloud service accessible through atelecommunications network. For example, a customer may purchase a groupof resources (such as data storage resources, processing resources,security resources, and the like) with each resource being acquired fora different purpose, such as development, testing, and manufacturing.Accordingly, it is generally desirable that access to each cloudinstance makes efficient use of network resources and any services forexchanging data with the cloud-based resources that may be purchased byor otherwise provided to the customer.

It is with these observations in mind, among others, that aspects of thepresent disclosure were conceived.

SUMMARY

In one aspect of the present disclosure, a method for transmitting dataover networks is provided. The method includes associating Customer EdgeVirtual Local Area Network (CE-VLAN) identifiers with an EthernetVirtual Connection (EVC). Each of the CE-VLAN identifiers is assigned toa respective Virtual Private Cloud (VPC) of a cloud computingenvironment and the EVC extends between a first network and the cloudcomputing environment through a second network. The EVC is alsoconfigured to transmit packets including any of the CE-VLAN identifiersto the cloud computing environment. The method further includestransmitting a packet received from the first network and including oneof the CE-VLAN identifiers to the cloud computing environment using theEVC.

In another aspect of the present disclosure, a system for configuringnetwork devices is provided. The system includes a network controller incommunication with a first network. The network controller is adapted toestablish a connection through the first network between a secondnetwork and a cloud computing environment. The cloud computingenvironment includes resources, each of which is associated with arespective resource identifier. The connection established by thenetwork controller is adapted to carry traffic between the secondnetwork and the cloud computing environment for each of the resources.The network controller is further adapted to configure network devicesof the first network to receive packets from the second networkincluding any of the resource identifiers and to route packets includingany of the resource identifiers through the connection to the cloudcomputing environment.

In yet another aspect of the present disclosure, a method forcommunicating data through networks is provided. The method includesreceiving a packet for one of multiple resources of a computing system,each of the resources being associated with a respective firstidentifier, and the computing system being in communication with anetwork. In response to identifying the packet includes one of the firstidentifiers, a second identifier is inserted into the packet, the secondidentifier associated with a connection established through the networkfor handling packets for each of the resources. The packet is routedthrough the network and along the connection according to the secondidentifier and then transmitted from the network to the computing systemaccording to the first identifier associated with the resource.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram illustrating an exemplary networkenvironment in accordance with one implementation of the currentdisclosure.

FIG. 2 is a schematic diagram illustrating a network environment forproviding multiple Ethernet Virtual Connections (EVCs) between acomputing system, such as a customer network, and multiple instances ofa cloud environment through an intermediate network.

FIG. 3 is a schematic diagram illustrating a second network environmentfor providing an EVC between a computing system and multiple instancesof a cloud environment through an intermediate telecommunicationsnetwork.

FIG. 4 is a flowchart illustrating a method for utilizing multipleCustomer Edge Virtual Local Area Network (CE-VLAN) identifiers todeliver packets for multiple resources using an EVC.

FIG. 5 is a flowchart illustrating a method for configuring one or morecomponents of an EVC to route multiple CE-VLAN identifiers through anetwork.

FIG. 6 is a schematic diagram of an exemplary system to manage requestsfor network services and to provide dynamic connections in a network.

FIG. 7 is a flow chart illustrating an example method for communicatingbetween computing systems.

FIG. 8 is a diagram illustrating an example of a computing system whichmay be used in implementations of the present disclosure.

DETAILED DESCRIPTION

Aspects of the present disclosure involve systems, methods, computerprogram products, and the like, for facilitating communication withcloud-based platforms. More particularly, systems and methods disclosedherein facilitate efficient communication between computing systems ornetworks through an intermediate network. In one example, the computingsystems/networks may be a first network corresponding to a customer anda second computing environment that is a cloud-based platform includingmultiple virtual resources accessible using a computing device, such asa computing device of a customer who acquires or otherwise obtainsaccess to the resources of the cloud-based platform. In contrast toconventional methods in which a separate connection through theintermediate network is required for each virtual resource,implementations of the present disclosure enable communications betweenone or more devices of the first network and multiple cloud resourcesover a single connection extending through the intermediate network.

It should be appreciated that for purposes of the present disclosure,the term “customer” is used to refer to any entity that may operate oneor more computing systems and/or networks that communicate, at least inpart, with a second computing system or network through atelecommunications network. Also for purposes of the present disclosure,the telecommunications network over which such communications areexchanged between the customer network and one or more cloudenvironments is generally referred to herein as a “intermediate” or“service provider” network. In each case, the terms customer,intermediate, or service provider are used solely for clarity and shouldnot be construed as limiting. For example, to the extent the terms“customer network” and “intermediate network” are used herein, each suchterm should be more generally considered to refer to any networkcarrying out the functions described herein.

Communication between a customer network and a virtual cloud-basedresource may include establishing an Ethernet Virtual Connection (EVC)between the customer network and the virtual cloud-based resource. Inconventional systems, connecting the customer network with multiplevirtual resources associated with the customer and maintained in a givencloud environment may require separate EVCs for each virtual resourceand, as a result, a corresponding dedication of network resources formaintaining each EVC. Under this conventional approach, networkresources may be tied up for purposes of maintaining each EVC to itsrespective virtual resource even when each EVC is not in use.Accordingly, a customer may pay for transport services that go under- orunutilized and limited resources of the network may be inefficientlyallocated and not otherwise available for other uses.

The foregoing issues, among others, are addressed in implementations ofthe present disclosure by enabling communication between a customernetwork and multiple virtual resources, such as Virtual Private Clouds(VPCs), of a cloud environment over a single EVC. Packets received froma customer network destined for a VPC generally include an identifier,such as a Customer Edge Virtual Local Area Network (CE-VLAN) identifier,which is uniquely associated with one of the VPCs. In one implementationof the present disclosure, when such packets are received by a firstedge device of an intermediate network, a second identifier, such as aService Provider Virtual Local Area Network (SP-VLAN) identifier, isadded to the packet. The SP-VLAN identifier is associated with an EVCthat extends through the intermediate network such that components ofthe intermediate network route packets including the SP-VLAN identifierthrough the intermediate network to a second edge device using theassociated EVC. When the packet reaches the second edge device, theSP-VLAN identifier is removed and the packet is passed to the cloudenvironment for further processing and routing to the destination VPC inaccordance with the CE-VLAN identifier.

The foregoing approach may be used for packets destined for each ofmultiple VPCs maintained by the cloud environment. In other words, eachpacket intended for any VPC maintained by a given cloud environment maybe supplemented with a SP-VLAN identifier that causes each packet to berouted over a common EVC. The identifier may then be removed prior tothe packet reaching the cloud environment such that each packet isultimately routed to the correct VPC in accordance with its respectiveCE-VLAN identifier.

In one implementation, an administrator of other user associated with acustomer may dynamically assign or unassign CE-VLAN identifiers toexisting EVCs. For example, a user portal may be provided to enableaddition or removal of CE-VLAN identifiers to EVCs associated with thecustomer. The portal may, in some instances, communicate with a networkcontroller or components of the intermediate network through which theEVC extends to update routing information or otherwise configurecomponents of the intermediate network in accordance with the updatedassignments. For example, such configuration may include mapping aprovided CE-VLAN identifier to a second identifier, such as thepreviously discussed SP-VLAN identifier, that is used for routingpackets through the intermediate network using the EVC. Through thesystems and methods described, a customer may better utilize bandwidthof an EVC connecting the customer to a cloud environment whilemaintaining the separation of VPCs within the cloud environment.

In addition to economic benefits to customers associated with makingbetter use of provisioned services, the systems and methods disclosedherein also provide significant technical advantages for theintermediate network. As previously noted, under conventionalapproaches, communication between a first computing system (e.g., acustomer network) and multiple resources of a cloud-based or similarplatform through an intermediate network generally requires individualconnections for each resource and dedication of corresponding networkresources to support each connection. In contrast, the systems andmethods disclosed herein require only enough resources to support asingle connection over the intermediate network. As a result, resourcesthat would otherwise be used to support additional connections may beused for other purposes.

Additionally, communicating over a single connection provides moreefficient use of the resources dedicated to supporting the connection.For example, in conventional systems including multiple connections,each connection is generally provisioned to handle a certain maximumlevel of traffic. However, traffic for a given connection may only be ator near the maximum level at certain times of the day or week (e.g.,when performing a nightly or weekly update) while having relatively lowtraffic at other times. As a result, the total capacity of theconnections for such resources (either individually or collectively) issignificantly underutilized. In contrast, by using a single connectionfor multiple resources and by coordinating/scheduling known periods ofhigh traffic, the capacity of the single connection may be moreefficiently utilized. For example, updates or similar high trafficprocesses for one or more first resources may be scheduled to occurduring relatively low periods of traffic for one or more secondresources (and vice versa) such that the combined traffic is within thecapacity of the connection.

Although described herein as primarily being directed to communicationsoriginating from a customer network and intended for resources of acloud computing environment, it should be appreciated that thetechniques described herein may be applied more generally tocommunications between a source computing system or network and multipleresources of a destination computing system or network using a singleconnection through an intermediate network. In one implementation,packets originating in the cloud environment may be directed to multipleresources associated with a customer using similar techniques asdescribed above for transmitting packets form the customer network tothe resources of the cloud environment. More specifically, a packet maybe provided by a cloud environment that includes a first identifierassociated with a resource of a destination network associated with acustomer. At an ingress device of an intermediate network, a secondidentifier corresponding to a connection through the intermediatenetwork may be inserted into the packet to facilitate routing along theconnection. At an egress device of the intermediate network, the secondidentifier may be removed and the packet may then be routed according tothe first identifier.

Beginning with FIG. 1, one example of a telecommunications networkconfiguration in accordance with the present disclosure is shown. Inparticular, FIG. 1 is a schematic diagram illustrating an exemplarynetwork operating environment 100. In general, the network environment100 provides for establishing communication sessions between networkdevices and for providing one or more network services. The environment100 includes an intermediate network 102 (also referred to herein simplyas “the network 102”), which may be provided by a wholesale networkservice provider. Portions of the intermediate network 102 may includeeither of IP-based or non IP-based routing. The intermediate network 102may include devices utilizing time division multiplexing (TDM) or plainold telephone service (POTS) switching and suitable components ordevices for converting TDM and/or POTS-based traffic to some form ofIP-based traffic. The intermediate network 102 includes numerouscomponents such as, but not limited to gateways, switches, and routers,which enable communication and/or provide services across theintermediate network 102, but are not shown or described in detail herebecause those skilled in the art will readily understand thesecomponents.

The intermediate network 102 may be configured to interconnect multiplesecondary networks, such as customer network 106 which can includecommunication devices such as, but not limited to, a personal computer110 connected to a customer network device 114, such as a router,firewall, gateway, switch, or other network device. Although shown inFIG. 1 as computer 110, the communication devices may include any typeof communication device that receives a multimedia signal, such as anaudio, video or web-based signal, and presents that signal for use by auser of the communication device. For example, a VoIP telephone or VoIPenabled device may be used to facilitate communication through theintermediate network 102 with the public switched telephone network(PSTN). The communication and networking components of the customernetwork 106 enable a user at the customer network 106 to communicatethrough the intermediate network 102 to other communication devicesand/or networks, such as the PSTN 126, the Internet, a cloud network142, and/or other customer networks. Components of the customer network106 are typically home- or business-based, but they can be relocated andmay be designed for easy portability. For example, the communicationdevice 110 may be a wireless (e.g., cellular) telephone, smart phone,tablet or portable laptop computer. In some implementations, multiplecommunication devices in diverse locations that are owned or operated bya particular entity or customer may be connected through theintermediate network 102.

The customer network 106 typically connects to the intermediate network102 via a border network 122, such as one provided by an InternetService Provider (ISP). The border network 122 is typically provided andmaintained by a business or organization such as a local telephonecompany or cable company. The border network 122 may providenetwork/communication-related services to their customers. In contrast,the communication device 120 accesses, and is accessed by, theintermediate network 102 via a public switched telephone network (PSTN)126 operated by a local exchange carrier (LEC). Communication via any ofthe networks can be wired, wireless, or any combination thereof.Additionally, the border network 122 and PSTN 126 and the border network122 may communicate, in some implementations, with the network 102through respective provider edges 130, 132. For ease of instruction,only three communication devices 110, 115, 120 are shown communicatingwith the network 102; however, numerous such devices, and other devices,may be connected with the intermediate network 102, which is equipped tohandle enormous numbers of simultaneous communications.

An operator of the intermediate network 102 may configure the network102 in any manner to facilitate the routing of communications throughthe network. For example, the intermediate network 102 may include aseries of interconnected networking devices, such as routers andswitches, that receive a communication, analyze the communication todetermine a destination, and route the communication to a connectednetworking device to get the communication closer to a destination oregress point (such as provider edge 131). To determine which routesthrough the network to utilize to route a received communication orpacket, components of the network may receive route information throughone or more route announcing sessions between the devices. These routeannouncing sessions provide Layer 3 routing information between thecomponents of the network and between different networks so thatcomponents of the intermediate network 102 and other networks maydetermine how to route received communication packets.

One particular example of the announcement of Layer 3 routinginformation occurs in a Border Gateway Protocol (BGP) announcement. Ingeneral, BGP information (or BGP session, BGP feed or BGP data) involvesa table of Internet Protocol (IP) prefixes which designate networkconnectivity between autonomous systems (AS) or separate networks. BGPinformation for a network route may include path (including next-hopinformation), network policies, and/or rule-sets for transmission alongthe path, among other information. The BGP feed may also includeInterior Gateway Protocol (IGP) information for network routes within anAutonomous System (AS) or network and/or other network information thatpertains to the transmission of content from the network. However, BGPinformation mainly describes routes used by the intermediate network 102to connect to external networks or customers (such as border network 122and virtual cloud environment 142) while IGP information describesroutes through the network to connect one provider edge (such asprovider edge 132) to another provider edge (such as provider edge 131)through the network 102.

The network 102 is provided as an example to illustrate various aspectsof telecommunications relevant to the present disclosure.Implementations of the present disclosure are not limited to thespecific implementation illustrated in FIG. 1. Rather, the conceptsdiscussed herein are more generally applicable to systems for managingand configuring devices within telecommunications networks, such as thenetwork 102.

In one instance, the network 102 may provide a connection between acustomer network 106 and a cloud environment 142 such that the customermay request resources from the public cloud and access those resourcesthrough the network. In particular, a customer may purchase or otherwiseacquire resources maintained in the cloud environment 142 to executeprocesses on the resources. Such resources are indicated in FIG. 1 asVirtual Private Clouds (VPCs) 144A-C. To utilize such resources 144A-C,the network 102 may provide a connection between devices of the customernetwork 106 (such as customer device 110) and the cloud environment 142.More particularly, one or more devices of the customer network 106 mayconnect to and provide/receive data and packets through provider edge132, network 102, and provider edge 131. As explained in more detailbelow, the connection facilitated by the network 102 may be a connectionover a public portion of the network 102 or a connection over a privateor dedicated portion of the network. Regardless of the type or constructof the connection, the network 102 thus provides a communication pathbetween the customer network 106 and the cloud environment 142 tofacilitate the use of cloud resources 144A-C by the customer.

As illustrated in FIG. 1, the network environment 100 may furtherinclude a network controller 136 in communication with the network 102.The network controller 136 may perform various functions, includingconfiguration of components of the network 102. For example, the networkcontroller 136 may be accessible by an administrator or operator of thenetwork 102 such that the administrator or operator may modify aspectsof the network 102. Such modifications may include, without limitation,adding or removing components from the network 102, obtaining data fromcomponents of the network 102, configuring components of the network102, and provisioning services over the network 102. In certainimplementations, the network controller 136 may receive or otherwisefunction in response to data or requests provided by devices of thecustomer network 106. For example, and without limitation anadministrator or other user associated with the customer network 106 mayprovide information regarding VPCs used by the customer and requestsregarding how data exchanged between such VPCs and devices of thecustomer 106 should be handled by the network 102. In response to suchinformation and requests, the network controller 136 may configure orotherwise modify aspects of the network 102 or components of the network102 in accordance with the request such that data exchanged over thenetwork 102 may be in accordance with the preferences provided bydevices of the customer network 106. As further described below, suchinteraction between devices of the customer network in 106 and thenetwork controller 136 may be facilitated, at least in part, by a portalor similar user interface accessible by an administrator or other userassociated with the customer network 106. Although illustrated in FIG. 1as being separate but communicatively coupled with the network 102, itshould be appreciated that the network controller 136 may beimplemented, in whole or in part, by one or more components of thenetwork 102.

FIG. 2 is a schematic diagram illustrating a first network environment200 for providing multiple EVCs 210-214 between a customer communicationdevice 222, which may be part of a customer network and multiple VPCs204-208 of a cloud environment 242 through an intermediate network 202.Many of the components of the network environment 200 are the same orsimilar to components in the network environment 100 of FIG. 1. Forexample, customer device 222 may be similar to the communication device110 described above, as is network 202 similar to network 102 andvirtual cloud environment 242 similar to virtual cloud environment 142.Further, provider edge 216 and provider edge 218 may be networking edgedevices as also described above. Also, the network controller 236 may besimilar to the network controller 136 of FIG. 1. More clearly shown inthe network environment 200 of FIG. 2 are the connections formed throughnetwork 202 to facilitate communication between the customercommunication device 222 and the virtual cloud environment 242.

The network environment 200 further includes a customer network device220 disposed between the customer communication device 222 and thenetwork 202. The customer network device 220 may be any suitable networkdevice of a customer network or a border network for facilitatingcommunication between the customer communication device 222 and thenetwork 202. For example and without limitation, the customer networkdevice 220 may include one or more of a modem, a router, a gateway, aswitch, or any other suitable physical or logical network device.

As discussed above, a customer may purchase or otherwise utilizemultiple cloud instances or VPCs 204-208 for the execution of thecustomer processes. The VPCs 204-208 may be utilized for a variety ofreasons, such as security concerns, redundancy, performance metrics, andthe like. For example, a first VPC (such as VPC-A 204) may be utilizedby a customer for development of a project while a second VPC (such asVPC-B 206) may be utilized for testing of newly developed projects. Thecustomer may desire to maintain the VPCs 204, 206 separately such thatchanges made within the development VPC do not change or otherwiseaffect the testing portion of the project. The separation of the VPCs204-208 may be virtual within the cloud environment or may be physicallyseparate on different physical resource devices. Regardless of themechanism or technique to separate the VPCs 204-208 in the cloudenvironment 242, one or more customer communication devices, such ascustomer communication device 222 may be connected to multiple resourcesof the cloud environment through the network 202.

In the particular implementation of FIG. 2, a separate connectionbetween the customer communication device 222 and each VPC 204-208 inthe cloud environment 242 is provided over the network 202. Inparticular, the network controller 236 may create an individual EVC210-214 through the network 202, each of which connects the customercommunication device 222 to a respective one of the VPCs 204-208. TheEVCs 210-214 provide an Ethernet tunnel through the network 202 betweenthe customer communication device and the cloud environment 242. Asshould be appreciated, the multiple connections 210-214 between thecustomer communication device 222 and the VPCs 204-208 may includeadditional costs to set up for the network 202 and may be inefficient toprovide the connection to the cloud services to the customer.

In a more particular example, a customer may desire to connect to threeVPCs 204-208 established in the cloud environment 242 using the customercommunication device 222. To do so, the customer may communicate withthe cloud environment 242 (or an administrator of the cloud environment)to establish the parameters of the VPCs 204-208. Regardless of themethod utilized to create or otherwise acquire the VPCs 204-208, acustomer network device 220 may be configured to receive and routecommunications from the customer communication device 222 intended forthe VPCs 204-208. For example, the customer network device 220 may beconfigured to identify packets or other communications that includeCE-VLAN identifiers (or similar identifiers) associated with one of theVPCs 204-208 of the cloud environment 242 and to route such packets tothe VPCs. A customer may also communicate with the network controller236 to request connectivity to the VPCs 204-208 through the network 202.The network controller 236, in turn, may provision or configure networkdevices (such as provider edge 216 and provider edge 218) to create EVCs210-214 for each VPC 204-208 associated with the customer communicationdevice 222. The customer may also provide the CE-VLAN identifiersutilized by the customer for each VPC 204-208 such that components ofthe network 202 may be configured by the network controller 236 to routereceived communication packets to each VPC 204-208 using respective EVCs210-214. In this manner, EVCs 210-214 are created through the network202 to connect customer communication device 222 with the VPCs 204-208of the cloud environment 242 associated with the customer.

For example, a customer may assign CE-VLAN identifier A with VPC-A 204executing on cloud environment 242 and CE-VLAN identifier B with VPC-B206. The customer may then provide CE-VLAN identifier A and CE-VLANidentifier B to the network controller 236, along with identifying VPCinformation. In response to the received information, the networkcontroller 236 may determine that two EVCs 210, 212 are to beestablished through the network 202 to establish connects between thecustomer communication device 220 and the VPCs 204, 206. The networkcontroller 236 may further determine which network devices (here,provider edge 216 and provider edge 218) are to be included in the EVCs210, 212 and provision those devices to route packets that includeCE-VLAN identifier A in the communication along EVC 210 and packets thatinclude CE-VLAN identifier B along EVC 212. The network controller 236may also determine which resources of cloud environment 242 are includedin VPC-A 204 and VPC-B 206 so that packets may be routed from provideredge 218 to the correct VPC 204, 206 of the cloud environment 242.Further, through the exchange of routing information with components ofthe network 202 (and more particularly, provider edge 216), the customernetwork device 220 may be configured to route communication packets withCE-VLAN identifier A and CE-VLAN identifier B to provider edge 216 forinclusion along the EVCs 210, 212. In other implementations, the EVCs210-214 may utilize different components of the network 202 such thatcommunications with CE-VLAN identifier A may be routed to a first edgedevice of the network 202 while communications with CE-VLAN identifier Bmay be routed to a second edge device.

Although illustrated as separate connections 210-214 in the network 200of FIG. 2, it should be appreciated that various configurations may beutilized in connecting the customer communication device 222 to thecloud environment 242. For example, the customer communication device222 may connect to the network 202 through one or more communicationports, sometimes referred to as a User Network Interfaces (UNIs).Through a UNI, components of the network 202 receive communicationpackets intended for the cloud environment 242. In a similar manner,components of the network 202 may communicate with the cloud environment242 through one or more communication ports. Further, an exchange ofrouting information, such as BGP information, may occur to allowcomponents of the network 202 to transmit and receive packets from thecustomer communication device 222 and the cloud environment 242 at aLayer 3 communication level. Similarly, components of the network 202may announce or exchange routing information (such as IGP information)within the network 202 to route communications between provider edges ofthe network, such as provider edges 216, 218. In addition to the Layer 3connection, components of the network 202 may establish a private Layer2 connection between the customer communication device 222 and the cloudenvironment 242. Such Layer 2 connections, sometimes referred to as aPeer-To-Peer (P2P) connections, allow for secure communication ofpackets between the customer communication device 222 and each VPC204-208 of the cloud environment 242.

Providing individual P2P connections between the customer communicationdevice 222 and the cloud instances 204-208 may provide some benefits tothe customer relating to security and reduced bandwidth requirements pertunnel. However, setting up individual communication tunnels through thenetwork 202, such as illustrated by EVCs 210-214 of FIG. 2, requiressignificant time and coordination between the customer communicationdevice 222, the customer network device 220, the network controller 236,and components of the network 202, with such requirements applyingwhenever a new VPC is created in the cloud environment 242. Further,establishing separate EVCs 210-214 may prevent a customer from utilizingall of the purchased bandwidth of the EVCs. For example, EVC 210 mayconnect the customer communication device 222 to a VPC-A 204, which maybe predominantly used during daytime hours while EVC 212 may connect thecustomer to VPC-B 206, which may be predominantly utilized duringnighttime hours. In such a scenario, EVC 210 may remain idle orsubstantially idle during nighttime hours while EVC 212 may be idle orsubstantially idle during daytime hours, such that only approximately50% of the total bandwidth purchased by the customer to implement theEVCs 210,212 is used at any given time.

In contrast to implementing an EVC for each VPC, shared usage of an EVCfor traffic associated with multiple VPCs may make more efficient use ofbandwidth purchased or otherwise acquired by a customer. For example, inthe previous example, the traffic intended for each of VPC-A 204 andVPC-B 206 may both be transmitted through the network 202 over EVC 210.Given the observed traffic patterns, EVC 210 would predominantly carrytraffic for VPC-A 204 during the day and VPC-B 206 during the night. Asa result, the total bandwidth and resources used to implement EVC 210are more efficiently utilized than in the case where traffic for VPC-A204 and VPC-B 206 are transmitted through separate EVCs. Such animplementation is now provided in more detail in the context of FIG. 3.

FIG. 3 is a schematic diagram illustrating a second network environment300 for providing connectivity between a customer communication device322 and multiple VPCs 304-308 of a cloud environment 342 via an EVC 318extending through a telecommunications network 302. Similar to thenetwork configuration 200 of FIG. 2, the network environment 300 of FIG.3 includes a customer communication device 322 connected to multipleVPCs 304-308 of a cloud environment 342 through the network 302 and anetwork controller 336 for facilitating functions of the network 302.However, in contrast to the network environment 200 of FIG. 2, in thenetwork environment 300 of FIG. 3, the packets intended for the multipleVPCs 304-308 are transmitted to the cloud environment 342 over a singleEVC 318.

In one particular implementation, the customer communication device 322transmits all communications packets intended for the VPCs 304-308 alongone communication path through customer network device 320, arriving atprovider edge 310. Similar to the previous example, communicationpackets arriving at the provider edge 310 may include a CE-VLANidentifier (or similar identifier) associated with one of the VPCs304-308 of the cloud environment 342, the CE-VLAN identifiercorresponding to an intended destination of the packet. However, ratherthan transmit the packets along separate EVCs for each of the VPCs, aswas the case in FIG. 2, all communication packets intended for VPCs304-308 are instead transmitted through the network 302 along a singleEVC 318 extending between provider edge 310 and provider edge 312.

In one implementation (described in more detail below), when the ingressprovider edge 310 receives a packet to be transmitted over the EVC 318to one of the VPCs 304-308, the ingress provider edge 310 may insert anidentifier into the header of the packet. For example, the ingressprovider edge 310 may insert a network-specific VLAN identifier (alsoreferred to herein as a “Service Provider VLAN” (SP-VLAN) identifier)for routing of the packet through the network 302. Notably, the SP-VLANidentifier is inserted into the packet in addition to the CE-VLANidentifier of the packet identifying the particular destination VPC forthe packet. The SP-VLAN identifier is then used by components of thenetwork 302 to route the packet through the network 302 along the EVC318 to an egress provider edge 312.

When the packet reaches the egress provider edge 312, the egressprovider edge 312 may remove the SP-VLAN identifier from the packet. Theegress provider edge 312 may then transmit the packet to the cloudenvironment 342 in accordance with the CE-VLAN identifier, which hasbeen retained within the packet. The packet may then be routed to theappropriate VPC 304-308 by the cloud environment.

With reference to FIG. 3, FIG. 4 is a flowchart illustrating a method400 for facilitating communication between a customer communicationdevice 322 and one or more VPCs 304-308 of a cloud environment 342 overa single connection 318. The operations of the method 400 may generallybe executed by the network controller 336 and/or one or more componentsof the network 302 illustrated in FIG. 3. For example, the networkcontroller 336 may dynamically connect and configure components of thenetwork 302 to set up the connection 318 across the network 302 and toenable communication through the connection 318 once established.

In one instance, the customer may be provided access to the controller336 (such as through a portal or similar interface) such that thecustomer may establish an EVC 318 and/or modify a list of CE-VLANidentifiers assigned to the EVC 318. The list of CE-VLAN identifiers maythen be used to configure components of the network 302, such as theprovider edge 310, to recognize packets having one of the CE-VLANidentifier. The provider edge 310 may modify any recognized packets,(e.g., by inserting a SP-VLAN identifier into the packet), such that thecomponents of the network 302 route the packet through the network 302using the EVC 318. Accordingly, to the extent the list of CE-VLANidentifiers includes multiple CE-VLAN identifiers assigned to the EVC318, the method 400 facilitates communication between the customercommunication device 322 and multiple VPCs over the EVC 318.

Beginning in operation 402, the network controller 336 may receive achange request from the customer regarding traffic, the change requestfor adding one or more CE-VLAN identifiers or deleting one or moreexisting CE-VLAN identifiers, each of the CE-VLAN identifiers associatedwith a respective VPC of the cloud environment 342. For example, acustomer may have provision or purchased one or more VPCs 304-308 orother resources from a vendor or service provider of the cloudenvironment 342. As mentioned above, such resources 304-308 may be,among other things, data storage, compute resources, security resources,or any other virtual resource available from a virtual cloudenvironment. After acquiring a new resource, the customer may submit arequest to the network controller 336 to add/assign a CE-VLAN identifierto an existing EVC 318 between the customer communication device 322 andthe cloud environment 342 within which the new resource is located. Ifno EVC exists, the request may also trigger the creation of the EVC 318between the customer communication device 322 and the cloud environment342 through the network 302. At some later time, the customer maypurchase an additional VPC from cloud environment 342 and associate anew unique CE-VLAN identifier with each of the new VPC and the EVC 318.

For purposes of the following example, it is assumed that VPC-C 308 ofFIG. 3 is a new VPC obtained by the customer. It should be appreciatedthat any reference to the VPC 308 is intended merely as an example andthe following example applies more generally to any resource of thecloud environment 342 that may be acquired by the customer.

After the new VPC 308 is obtained, the customer may request acommunication connection to the cloud environment 342 to access the newVPC 308. In certain implementations, the customer may access a dynamiccontroller interface of the network controller 336 to requestconnectivity to the new VPC 308. The network controller 336 may, inturn, begin a process to provide communication between the customercommunication device 322 and the VPC 308.

In operation 404, the customer provides connectivity information betweenthe customer communication device 322 and the cloud environment 342,such as through the dynamic controller interface of the networkcontroller 336. In particular, the customer 322 may provide, among otherthings, customer identification information, VPC identification and/orconfiguration information, information for an existing EVC (e.g., theEVC 318 of FIG. 3), a CE-VLAN identifier to be added to the EVCassociated with the connection, and the like. In some instances, some ofthe above information may be provided through the exchange of Layer 3routing information (such as through a BGP session) and Layer 2transport information.

With the customer-cloud connectivity information received, the networkcontroller 336 may then configure one or more devices of the network(and in particular, devices associated or included in the EVC 318) toconnect the customer communication device 322 to the cloud environment342 (operation 406). As part of the configuration process, the networkcontroller 336 may determine which network devices are included in EVC318. For example, the network controller 336 may determine that provideredge 310 and provider edge 312 are included in EVC 318. In someimplementations, the devices identified as being included in EVC 318 mayalso include customer side components, such as customer network device320, and cloud environment side components, such as devices associatedwith VPCs 304-308 or a cloud environment router (not shown).

In operation 408, the network controller 336 may begin configuring orprovisioning the components included in EVC 318 with respect to theCE-VLAN identifier of the new VPC 308. For example, the networkcontroller 336 may configure a customer router 320 to route packets withthe particular CE-VLAN identifier to provider edge 310 of the network302. In some instances, the network controller 336 may communicate withthe customer network device 320 and instruct or otherwise configure thecustomer network device 320 to accept packets from the customercommunication device 322 with the particular CE-VLAN identifier androute such packets to provider edge 310. In another example, provideredge 310 (or another network device) may announce BGP routinginformation that instructs the customer router 320 to provide packetsintended for VPC 308 to the provider edge 310. Regardless of theimplementation, the customer network device 320 is configured to routepackets with the CE-VLAN identifier to provider edge 310, whichfunctions as an ingress device for the network 302. Other packets withdifferent CE-VLAN identifiers assigned by the customer may also betransmitted to the provider edge 310 for transmission along EVC 318 tocloud environment 342.

In operation 410, the network controller 336 may configure components ofthe network 302 to route received packets with the particular CE-VLANidentifier along EVC 318. In one particular implementation, the networkcontroller 336 may establish, through shared IGP information, EVC 318through the network 302 such that EVC 318 extends between provider edge310 (connected to the customer network device 322) and provider edge 312(connected to the cloud environment 342). To create EVC 318, the networkcontroller 336 may also configure one or more of the components of thenetwork 302 to receive and/or transmit packets that include differentCE-VLAN identifiers associated with other VPCs or resources of the cloudenvironment 342.

In one implementation, the network 302 components of the EVC 318 may beconfigured to route packets through the network 302 based on a ServiceProvider Virtual Local Area Network (SP-VLAN) identifier. Moreparticularly, SP-VLAN identifiers may be generated by or provided to thenetwork controller 336 and uniquely associated with respective EVCs bythe network controller 336 such that any packet including a givenSP-VLAN identifier is routed through the network 302 using the EVCassociated with the included SP-VLAN identifier. Notably, the SP-VLANidentifier may be included in addition to and independent of a CE-VLANidentifier that may also be included in the packet. As a result, theSP-VLAN identifier may be used to route communications through thenetwork 302 and the CE-VLAN identifier may be used to ultimately directsuch communications to the resource of the cloud environment 342associated with the CE-VLAN.

As explained in more detail below, in certain implementations, theprovider edge 310 may insert the SP-VLAN into a received packet whilemaintaining the CE-VLAN identifier within the packet. The components ofthe network 302 may then be configured to route a packet based on theSP-VLAN along EVC 318 to provider edge 312, where the SP-VLAN may beremoved from the packet for transmission to cloud environment 342.

In operation 412, the network controller 336 may configure one or moreassets of the cloud environment 342 associated with the network 302. Forexample, the network controller 336 may establish a connection 316between the network 302 (more particularly the provider edge 312) andthe cloud environment 342. In some instances, this may includerequesting a communication port from the cloud environment 342 throughwhich the provider edge 312 may provide communication packets or frames.As such, the network 302 may be assigned an identifier with which thecloud environment 342 may identify the network 302. In addition, Layer 3information (such as BGP information) may be exchanged betweencomponents of the network 302 and the cloud environment 342 to establisha communication path 316 between the network 302 and the cloudenvironment 342. With the account information and BGP information, thecloud environment 342 may provide an open port to the provider edge 312of the network 302 to receive communication packets intended forresources of the cloud environment 342.

In certain implementations, once a communication port is provided by thecloud environment 342 and a communication link 316 is establishedbetween the network 302 and the cloud environment 342, the networkcontroller 336 may also configure the communication port of the cloudenvironment 342 to accept packets including CE-VLAN identifiersassociated with the EVC 318 from the customer communication device 322.For example, the network controller 336 may call one or more ApplicationProgramming Interfaces (APIs) to communicate with and configure aspectsof the cloud environment 342. Through the APIs, the network controller336 may provide a list of CE-VLAN identifiers associated with the VPCs304-308 utilized by the customer to the cloud environment 342. Incertain implementations, the cloud environment 342 may also create avirtual interface associated with the communication port of theconnection 316 to manage the receipt and transmission of packets on thepath. This virtual interface may be provided with the CE-VLAN tagidentifiers for use by the cloud environment 342 as explained below.

Through the method 400 of FIG. 4, the network controller 336 mayadd/assign a CE-VLAN identifier associated with a VPC-C 308 to an EVC318 extending through the network 302. The EVC 318 may be associatedwith other CE-VLAN identifiers associated with other VPCs (e.g., VPC-A304 and VPC-B 306) of the cloud environment 342 such that the customermay utilize the single EVC 318 to carry packets intended for any of VPCs304-308. In other words, packets including any of the CE-VLANidentifiers are transmitted in a single stream over a singlecommunication path or route through the network 302, regardless of theirultimate destination. The cloud environment 342 may then be configuredto recognize or determine the CE-VLAN identifiers included in each ofthe received packets and provide the packets to the intended VPC. Inthis manner, communications between the customer and multiple VPCs304-308 are multiplexed into a single stream of packets that can betransmitted on a single EVC 318 or path through the network.

Several advantages may be realized for the customer and/or the network302 through the use of VLAN separation as included in implementations ofthe present disclosure. For example, a single route through the network302 may be easier to manage for the customer by consolidating severalsecure routes or tunnels through the network 302 into a single route andapplying global routing features to the route. Further, creating orsetting up the routes between the customer communication device 322 andthe cloud environment 342 may occur faster (due to the fewer number ofcomponents to be configured) and, in some instances, may be createddynamically in response to a request by the customer. For example, thecustomer may be provided with a mechanism or system to dynamicallyrequest a connection to the cloud environment 342 or a cloud instance304 by providing the routing and connectivity information to a networkcontroller 336. The network controller 336 may then automaticallyconfigure ports of components of the network 302 to define acommunication path through the network 302. The network controller 336may also execute one or more operations (such as through an API) relatedto controllable aspects of the cloud environment 342 to create thecommunication path. Tearing down a route to the cloud environment 342may also occur dynamically in a similar manner. In addition, fewerroutes provided to the customer by the network 302 may provide thenetwork with more resources and devices to provide services to othercustomers. Thus, by utilizing CE-VLAN tags to separate packets intendedfor multiple VPCs 304-308, the network 302 may operate more efficientlyand provide the customer with improved service when interacting with thecloud environment 342.

FIG. 5 is a flowchart illustrating a method 500 for configuring one ormore components of an EVC 318 of a network 302 to route multiple CE-VLANidentifiers to a cloud environment 342. In one implementation, theoperations of the method 500 may be performed by the network controller336 of FIG. 3. In other implementations, one or more of the operationsmay be performed by other network components including components of thenetwork 302 or a network associated with the customer (such as customernetwork 106 or border network 122 illustrated in FIG. 1). Beginning inoperation 502, the network controller 336 receives a request to add aCE-VLAN identifier to an EVC 318 of a customer, the EVC 318 extendingthrough the network 302. In one implementation, the request is receivedthrough a customer portal or similar user interface in communicationwith the network controller 336. As also explained above, the requestmay include identifying information, including but not limited to acustomer identifier, an EVC identifier, a CE-VLAN identifier, and thelike.

In operation 504, the network controller 336 may map the receivedCE-VLAN identifier to an SP-VLAN identifier that is uniquely associatedwith the EVC 318. This mapping may also be stored in one or moredatabases accessible by the network controller 336 for future use inconfiguring the network 302. In operation 506, the network controller336 provides one or more routing instructions or tables to components ofthe network 302 defining included in the EVC 318 to route packets withincluding the CE-VLAN identifier along the EVC 318. In oneimplementation, the components may be configured to identify the SP-VLANidentifier of a packet and route the packet based on the SP-VLANidentifier through the network 302, such routing being along the EVC318. Further, the instructions provided by the network controller 336may include instructions to set a VLAN preservation flag to retain theCE-VLAN identifier of the packet throughout routing along the EVC 318.Thus, although the network 302 may utilize the SP-VLAN identifier toroute the packet within the network 302, the CE-VLAN identifier ismaintained within the packet for later routing use upon egress from thenetwork 302 (e.g., routing within the cloud environment 342).

In operation 508, the network controller 336 may receive anacknowledgement message from the components of the EVC 318 that therouting instructions have been received and executed. As noted inoperation 510, this acknowledgement message may, in some instances, beprovided to the customer through a portal or user interface. In thismanner, the customer may utilize the portal or interface to add aCE-VLAN identifier to an EVC 318 of the network 302.

FIG. 6 is a schematic diagram of an exemplary system 600 to managerequests from a customer for network services and to provide dynamicconnections in a network in response to such requests. As illustrated inFIG. 6, the system 600 may include a dynamic controller 602, which, incertain implementations, may generally correspond to the networkcontroller 336 previously discussed in the context of FIG. 3. Throughthe dynamic controller 602, a customer may request to initiate or ceaserouting of packets including particular CE-VLAN identifiers along anexisting EVC 318 through the network 302. Thus, a dynamic controller 602is shown for use by a customer to manage functionality for buildingnetwork paths, which may include EVCs 318 or other connections. Whilenot being limited to any particular programming language, the dynamiccontroller 602 may include a multi-threaded, high-performance,high-reliability, and real-time application that services connectionrequests either from a portal 608 (such as a customer portal/webinterface or application) or directly from calls using an applicationprogramming interface (API) 606. The dynamic controller 602 is incommunication with or otherwise has access to information about networkresources 630, such as network resource 630A, network resource 630B, andnetwork resource 630C. Such network resources 630, which may also bereferred to as network elements, may include switches, routers, or othersuch networking resources associated with an intermediate network, metroring networks, or other networks that form or are otherwise associatedwith a service provider network, such as the network 302 of FIG. 3, andmay be involved in providing Layer 2 interconnectivity in the network.

The dynamic controller 602 is further connected to or otherwise hasaccess to one or more databases 620. In general, the databases 620 mayinclude data that may be accessed and used by the dynamic controller 602when executing various functions, such as establishing connectionsthrough a telecommunications network. In one implementation, thedatabases 620 include an inventory database (DB) 620A which may containinformation about the topology of the network resources 630, the varioustypes of each network resource 630, how the network resources 630 arecommonly used for a network connection (e.g., how the resource ispositioned hierarchically within a connection path), and how the networkresources 630 are physically interconnected, or other information thatmay be useful for establishing a connection through a network. As such,the inventory database 620A may be referenced by the dynamic controller602 to generate the path, including the order of devices in a connectionpath. For example, the inventory database 620A may contain informationindicating that the network resource 630A is a switch utilized with ametro ring accessible by a particular customer device. The resourcedatabase 620B may contain or have access to information aboutport/interface availability for each of the network resources 630,configuration attributes needed to configure interfaces for each of thenetwork resources 630, and the like. For example, the resource database620B may contain information indicating that the network resource 630Ahas an available port P1, and that configuration attributes X, Y, and Zare needed to configure the network resource 630A for a given networkconnection. During operation, the dynamic controller 602 may communicatewith and update the information stored within the databases 620 as thedynamic controller 602 is building, modifying, or tearing down variousnetwork connections, as described herein.

The dynamic controller 602 may further have access to a billing andreporting database 622 that may further be coupled to or otherwiseinclude data associated with a billing module 624 and a reporting module626 to facilitate billing- and reporting-related functions. The dynamiccontroller 602 may also be connected or otherwise have access to acustomer order database 618 to track orders and connections requested bycustomers. Information in either of the billing and reporting database622 and the customer order database 618 may be used by the dynamiccontroller 602 to build network connection paths or otherwise configuredevices of the connection paths. It should be understood that thedepicted databases are merely exemplary and that additional databases orstorage repositories are contemplated. In some implementations, theinformation from the databases 620, the customer order database 618, andthe billing and reporting database 622 may be aggregated for use by thedynamic controller 602.

The dynamic controller 602 may be in communication with any number ofdifferent devices, applications, modules, systems or components toexecute the functionality described herein. For example, the dynamiccontroller 602 may utilize a simulator 604, comprising an application orsystem operable to simulate a network connection path. The dynamiccontroller 602 may utilize a second API 640 to provide real-timemeasurement within a network. Such measurements may then be used by thedynamic controller 602 to determine whether any of the network resources630 has bandwidth for a new interface configuration or to otherwiseprovide statistics about the network resources 630. The dynamiccontroller 602 may also provide access to an operations (OPS) validationtool 610 to troubleshoot network connections and connection paths, andmay utilize a dynamic scheduler 616 to manage requests for connectionsreceived via the portal 608 and API 606.

As further shown in FIG. 6, the dynamic controller 602 may be connectedto a network service orchestration (NSO) system 614 and the NSO system614 may further be in communication with the network resources 630. Asdescribed herein, the dynamic controller 602 retrieves or accessesdevice configuration attributes that are needed to configure devices fora connection path and makes such configuration attributes available tothe NSO system 614. The NSO system 614 may include any configurationsystem and/or one or more computing and network devices which areoperable to provision a network connection by applying or otherwiseimplementing configurations defined by the device configurationattributes to any one of the network resources 630.

FIG. 7 is a flow chart illustrating an example method 700 forcommunicating across a network according to the present disclosure. Moreparticularly, the method 700 includes establishing a connection betweena first computing system or network and a second computing system ornetwork and transmitting traffic for multiple resources of the secondcomputing system or network using the connection. With reference to FIG.3, for example, the first computing system or network may correspond tothe customer communication device 322, the customer network device 320,or one or more networks including such devices, the second computingsystem or network may correspond to the cloud computing environment 342,and the intermediate network may correspond to the network 302. However,it should be appreciated that the first computing system or network maybe any suitable system or network capable of connecting to the secondcomputing system or network through the intermediate network and thesecond computing system or network may be any system or networkincluding multiple resources. For example, in one implementation, thefirst system or network may instead be the cloud computing environment342 and a customer network including multiple resources may be thesecond system or network.

At operation 702, a connection is established between the first systemand the second system. As previously discussed in the context of FIG. 3,such a connection may be, among other things, an EVC 318 extending fromthe customer communication device 322, through the network 302, to thecloud environment 342. Establishing the connection may include a networkcontroller, such as the network controller 336, configuring one or morenetwork devices of the intermediate network to provision the connection.For example, the network controller may configure at least a first edgedevice in communication with the first system/network (e.g., provideredge 310) and a second edge device in communication with the secondsystem/network (e.g., provider edge 312) to route traffic between thefirst and second systems/networks along the connection. In addition tothe edge devices, other devices of the intermediate network that arephysically and/or logically disposed along the network pathcorresponding to the connection may also be configured by the networkcontroller to route traffic along the connection.

After a connection is established between the first and secondsystems/networks through the intermediate network, one or more firstidentifiers may be associated with the connection (operation 704), witheach of the first identifiers may be assigned to a resource of thesecond system/network. As previously discussed, in one implementationthe first identifiers may be CE-VLAN identifiers such that each resourceof the second system/network is assigned a unique CE-VLAN identifier.One or more of the CE-VLAN identifiers may then be associated with theconnection through the intermediate network such that any packetsincluding the CE-VLAN identifiers associated with the connection may beidentified and routed through the intermediate network using theconnection.

In one implementation, association of identifiers to connections may befacilitated by a portal or similar interface accessible by anadministrator or other use associated with the first system/network.Through such an interface, the user may provide information regardingany cloud-based resources associated with the first system/network andselect through which connection communication with such resources shouldoccur.

In response to a first identifier being associated with the connection,the network controller may automatically communicate with and configureone or more components of the intermediate network (operation 706) suchthat the one or more components may identify any packets including thefirst identifier (operation 708). For example, referring to FIG. 3, thenetwork controller 336 may configure the provider edge 310 or otheringress device of the network 302 to identify packets received from thecustomer communication device 322 that include a CE-VLAN identifierassociated with the EVC 318. After configuration, the provider edge 310may identify a packet including a CE-VLAN identifier associated with theEVC 318.

In response, identifying a packet including the first identifier, theingress device may insert a second identifier associated with theconnection (operation 710). As a result, the packet may include each ofthe first identifier associated with a destination resource and a secondidentifier associated with a connection over which the packet is to betransmitted. As previously discussed, in one example implementation, oneexample of a second identifier may be a SP-VLAN identifier. Afterinserting the second identifier, the ingress device may begin routingthe packet through the intermediate network according to the secondidentifier (operation 712).

During the configuration operation 706, the network controller may alsoconfigure one or more additional components of the intermediate networkto facilitate communication using the connection. For example, one ormore devices within the intermediate network may be configured toidentify packets including the second identifier and to route packetsincluding the second identifier along a network path corresponding tothe connection.

The network controller may further configure an egress device of theintermediate network during operation 706. More specifically, thenetwork controller may configure such an egress device to identifypackets including the second identifier, remove the second identifierfrom such packets (operation 714) and then route the packets (nowincluding only the first identifier) according to the first identifier).In the example of FIG. 3, such an egress device may be the provider edge312. When configured by the network controller as described above, theprovider edge 312 may identify subsequently received packets includingthe SP-VLAN identifier and, when such a packet is identified, may removethe SP-VLAN identifier from the packet. The provider edge 312 may thenforward the packet to the cloud environment 342 according to the CE-VLANidentifier remaining in the packet.

FIG. 8 is a block diagram illustrating an example of a computing deviceor computer system 800 which may be used in implementations of thecomponents of the network disclosed above. For example, the computingsystem 800 of FIG. 8 may be the dynamic controller 602 discussed above.The computer system (system) includes one or more processors 802-806.Processors 802-806 may include one or more internal levels of cache (notshown) and a bus controller or bus interface unit to direct interactionwith the processor bus 812. Processor bus 812, also known as the hostbus or the front side bus, may be used to couple the processors 802-806with the system interface 814. System interface 814 may be connected tothe processor bus 812 to interface other components of the system 800with the processor bus 812. For example, system interface 814 mayinclude a memory controller 818 for interfacing a main memory 816 withthe processor bus 812. The main memory 816 typically includes one ormore memory cards and a control circuit (not shown). System interface814 may also include an input/output (I/O) interface 820 to interfaceone or more I/O bridges or I/O devices with the processor bus 812. Oneor more I/O controllers and/or I/O devices may be connected with the I/Obus 826, such as I/O controller 828 and I/O device 830, as illustrated.The system interface 814 may further include a bus controller 822 tointeract with processor bus 812 and/or I/O bus 826.

I/O device 830 may also include an input device (not shown), such as analphanumeric input device, including alphanumeric and other keys forcommunicating information and/or command selections to the processors802-806. Another type of user input device includes cursor control, suchas a mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to the processors 802-806and for controlling cursor movement on the display device.

System 800 may include a dynamic storage device, referred to as mainmemory 816, or a random access memory (RAM) or other computer-readabledevices coupled to the processor bus 812 for storing information andinstructions to be executed by the processors 802-806. Main memory 816also may be used for storing temporary variables or other intermediateinformation during execution of instructions by the processors 802-806.System 800 may include a read only memory (ROM) and/or other staticstorage device coupled to the processor bus 812 for storing staticinformation and instructions for the processors 802-806. The system setforth in FIG. 8 is but one possible example of a computer system thatmay employ or be configured in accordance with aspects of the presentdisclosure.

According to one implementation, the above techniques may be performedby computer system 800 in response to processor 804 executing one ormore sequences of one or more instructions contained in main memory 816.These instructions may be read into main memory 816 from anothermachine-readable medium, such as a storage device. Execution of thesequences of instructions contained in main memory 816 may causeprocessors 802-806 to perform the process steps described herein. Inalternative implementations, circuitry may be used in place of or incombination with the software instructions. Thus, implementations of thepresent disclosure may include both hardware and software components.

A machine readable medium includes any mechanism for storing ortransmitting information in a form (e.g., software, processingapplication) readable by a machine (e.g., a computer). Such media maytake the form of, but is not limited to, non-volatile media and volatilemedia. Non-volatile media includes optical or magnetic disks. Volatilemedia includes dynamic memory, such as main memory 816. Common forms ofmachine-readable medium may include, but is not limited to, magneticstorage medium; optical storage medium (e.g., CD-ROM); magneto-opticalstorage medium; read only memory (ROM); random access memory (RAM);erasable programmable memory (e.g., EPROM and EEPROM); flash memory; orother types of medium suitable for storing electronic instructions.

Implementations of the present disclosure include various steps, whichare described in this specification. The steps may be performed byhardware components or may be embodied in machine-executableinstructions, which may be used to cause a general-purpose orspecial-purpose processor programmed with the instructions to performthe steps. Alternatively, the steps may be performed by a combination ofhardware, software and/or firmware.

The description above includes example systems, methods, techniques,instruction sequences, and/or computer program products that embodytechniques of the present disclosure. However, it is understood that thedescribed disclosure may be practiced without these specific details. Inthe present disclosure, the methods disclosed may be implemented as setsof instructions or software readable by a device. Further, it isunderstood that the specific order or hierarchy of steps in the methodsdisclosed are instances of example approaches. Based upon designpreferences, it is understood that the specific order or hierarchy ofsteps in the method can be rearranged while remaining within thedisclosed subject matter. The accompanying method claims presentelements of the various steps in a sample order, and are not necessarilymeant to be limited to the specific order or hierarchy presented.

It is believed that the present disclosure and many of its attendantadvantages should be understood by the foregoing description, and itshould be apparent that various changes may be made in the form,construction and arrangement of the components without departing fromthe disclosed subject matter or without sacrificing all of its materialadvantages. The form described is merely explanatory, and it is theintention of the following claims to encompass and include such changes.

While the present disclosure has been described with reference tovarious embodiments, it should be understood that these embodiments areillustrative and that the scope of the disclosure is not limited tothem. Many variations, modifications, additions, and improvements arepossible. More generally, embodiments in accordance with the presentdisclosure have been described in the context of particularimplementations. Functionality may be separated or combined in blocksdifferently in various embodiments of the disclosure or described withdifferent terminology. These and other variations, modifications,additions, and improvements may fall within the scope of the disclosureas defined in the claims that follow.

We claim:
 1. A system for configuring network devices comprising: anetwork controller in communication with a first network, the networkcontroller adapted to: establish a connection through the first networkbetween a second network and a cloud computing environment, wherein thecloud computing environment includes a plurality of resources, each ofthe plurality of resources associated with a respective resourceidentifier, and the connection is adapted to carry traffic between thesecond network and the cloud computing environment for each of theplurality of resources; and configure a plurality of network devices ofthe first network to receive packets from the second network includingany of the resource identifiers and to route packets including any ofthe resource identifiers through the connection to the cloud computingenvironment.
 2. The system of claim 1, wherein the plurality of networkdevices includes an ingress device and the network controller is adaptedto configure the ingress device to receive packets including any of theresource identifiers and to insert a connection identifier associatedwith the connection into received packets that include any of theresource identifiers.
 3. The system of claim 1, wherein the plurality ofnetwork devices includes an egress device and the network controller isadapted to configure the egress device to remove a connection identifierassociated with the connection from packets received over the connectionand including any of the resource identifiers.
 4. The system of claim 1,wherein the connection is an Ethernet Virtual Connection (EVC) and theresources of the cloud computing environment are Virtual Private Clouds(VPCs).
 5. The system of claim 4, wherein each resource identifier is aCustomer Edge Virtual Local Area Network (CE-VLAN) identifier assignedto a respective one of the VPCs.
 6. The system of claim 1, wherein thecontroller is further adapted to receive a request to associate a newresource identifier with the connection and, in response to receivingthe request, to configure the plurality of network devices to receivepackets from the second network including the new resource identifierand to route packets including the new resource identifier through theconnection
 7. A method for communicating data through networks, themethod comprising: receiving a packet for a resource of a plurality ofresources of a computing system, each of the plurality of resourcesbeing associated with a respective first identifier, and the computingsystem being in communication with a network; in response to identifyingthe packet includes one of the first identifiers, inserting a secondidentifier into the packet, the second identifier associated with aconnection established through the network for handling packets for eachof the plurality of resources; routing the packet through the networkand along the connection according to the second identifier; andtransmitting the packet from the network to the computing systemaccording to the first identifier associated with the resource.
 8. Themethod of claim 7, wherein the packet is received at an ingress networkdevice of the network and the second identifier is inserted into thepacket by the ingress network device.
 9. The method of claim 7 furthercomprising, before transmitting the packet from the network to thecomputing system, removing the second identifier from the packet. 10.The method of claim 9, wherein the packet is transmitted from thenetwork by an egress network device and the second identifier is removedfrom the packet by the egress network device.
 11. The method of claim 7,wherein the connection established through the network is an EthernetVirtual Connection (EVC).
 12. The method of claim 7, wherein thecomputing system is a cloud-based computing environment.
 13. The methodof claim 7, wherein the packet is a first packet, the method furthercomprising: receiving a second packet for a second resource of theplurality of resources, the second resource being different than thefirst resource; in response to identifying the second packet includesone of the first identifiers, inserting the second identifier into thesecond packet; routing the second packet through the network and alongthe connection according to the second identifier; and transmitting thesecond packet from the network to the computing system according to thefirst identifier associated with the second resource.